Proton Mail, Infomaniak : la souveraineté de vos emails reste une illusion face aux règles dictées par Google

Proton Mail, La Poste, Infomaniak, Mailo... les messageries "souveraines" se multiplient. Mais elles reposent toutes sur le même protocole conçu en 1982 aux États-Unis, sans authentification native et sans chiffrement. Les normes de sécurité ajoutées depuis ont été définies par Yahoo, Cisco, Microsoft et Google. Et Gmail filtre une part considérable du trafic email mondial, sans que l'Europe ne puisse dire quoi que ce soit.

L'email donne l'impression d'être une infrastructure décentralisée. En réalité, les fondations techniques des services mail, leurs règles de délivrabilité et leurs standards de sécurité sont tous d'origine américaine.

SMTP a 43 ans et n'a jamais été pensé pour être sécurisé

SMTP, c'est le protocole qui fait circuler les emails d'un serveur à l'autre. Son nom complet est Simple Mail Transfer Protocol. Il a été formalisé en 1982 dans la RFC 821, un document technique rédigé par Jon Postel, chercheur à l'université de Californie du Sud, financé par la DARPA, l'agence de recherche militaire américaine. SMTP a été conçu pour un réseau fermé reliant quelques universités américaines. Pas pour un internet ouvert à des milliards d'utilisateurs.

Seulement voilà le problème : SMTP ne prévoit aucun mécanisme pour vérifier qui envoie quoi. Un serveur email peut revendiquer n'importe quelle identité d'expéditeur. Par défaut, le protocole fait confiance à tout le monde. C'est pour cette raison que le spam, le phishing et l'usurpation d'adresse email sont si difficiles à éradiquer : le protocole lui-même ne dispose d'aucun garde-fou natif.

Ce n'est pas une faille qu'on aurait oubliée de corriger. C'est une décision de conception délibérée. En 1982, la priorité était l'interopérabilité : que tout le monde puisse envoyer un email à chacun, le plus simplement possible. La sécurité n'était pas dans le cahier des charges. Quarante-trois ans plus tard, le protocole est toujours là, inchangé dans ses fondamentaux.

SPF, DKIM, DMARC : des rustines nées dans des labos américains

Face à l'explosion du spam dans les années 2000, trois standards ont été créés pour compenser les lacunes de SMTP. SPF (Sender Policy Framework) permet à un domaine de déclarer quels serveurs sont autorisés à envoyer des emails en son nom. DKIM (DomainKeys Identified Mail) ajoute une signature cryptographique à chaque email pour prouver qu'il n'a pas été modifié en transit. Enfin, DMARC (Domain-based Message Authentication, Reporting and Conformance) combine les deux et indique aux serveurs destinataires ce qu'ils doivent faire en cas d'échec : rejeter, mettre en quarantaine, ou laisser passer.

Ces trois standards ont été développés entre 2003 et 2012, principalement par des ingénieurs de Yahoo et Cisco. Ces derniers ont fusionné leurs travaux respectifs pour créer DKIM, avant qu'IBM, Microsoft et VeriSign ne contribuent à sa standardisation à l'IETF. DMARC, lui, a été conçu à partir de 2010 par un groupe incluant PayPal, Google, Microsoft et Yahoo, avant d'être publié en janvier 2012. L'IETF (Internet Engineering Task Force), l'organisme qui formalise les protocoles internet, les a ensuite publiés comme standards ouverts. Mais leur conception est américaine, et leur déploiement reste inégal. Des milliers de domaines, y compris des administrations publiques françaises, ne configurent pas correctement DMARC, voire ne l'implémentent pas du tout.

Ce n'est pas anodin. Un domaine sans DMARC peut être usurpé sans grande difficulté. Quelqu'un peut envoyer un email qui semble venir d'une mairie, d'une banque ou d'un ministère - et une partie des serveurs de messagerie l'acceptera. La France a progressé sur ce point pour les domaines en .gouv.fr, mais le chantier reste ouvert. Et partout ailleurs en Europe, la situation est comparable.

Google a changé les règles, sans demander l'avis de personne

Gmail est le service de messagerie le plus utilisé dans le monde. Cette position lui confère un pouvoir que peu de régulateurs ont mesuré. En pratique, si un email ne passe pas les filtres de Google, il n'arrive pas à destination - ou finit directement en spam. Il n'y a aucun recours possible, ni aucun arbitrage. La configuration de votre domaine passe simplement à la moulinette d'un algorithme.

En février 2024, Google a imposé de nouvelles exigences aux expéditeurs dits "en volume". Concrètement, cela inclut toute organisation qui envoie plus de 5000 emails par jour vers des adresses Gmail. Ces expéditeurs doivent obligatoirement :

• Avoir configuré SPF, DKIM et DMARC.
• Maintenir un taux de spam inférieur à 0,1%.
• Proposer un lien de désinscription accessible en un clic.

Ces règles sont raisonnables sur le fond. Mais elles ont été décidées unilatéralement par une entreprise privée américaine, appliquées à l'échelle mondiale, sans consultation internationale et sans aucun processus de standardisation préalable.

Microsoft a suivi en mai 2025, soit plus d'un an après Google, avec des exigences similaires pour Outlook.com, Hotmail.com et Live.com. Résultat : tous les opérateurs email du monde, y compris OVH, Infomaniak, La Poste, ou Proton, ont dû adapter leurs systèmes pour se conformer aux critères fixés à Mountain View et à Redmond. Une administration française souhaitant que ses emails arrivent chez des administrés utilisant Gmail n'a pas le choix. Elle doit jouer selon les règles de Google. Et il n'existe aucune autorité européenne pour arbitrer ce rapport de force.

Proton Mail est chiffré, hors des standards

Proton Mail est une entreprise suisse. Son infrastructure est répartie entre la Suisse, l'Allemagne et la Norvège. En 2025, suite à des incertitude législatives locales, Proton a commencé à migrer une partie de ses données hors de Suisse. Ses applications (web, iOS, Android) sont open source, même si son backend reste propriétaire. Ces caractéristiques en font un choix cohérent pour quiconque cherche à réduire son exposition aux GAFAM. Mais le service reste assujetti à une limite du protocole email : l'interopérabilité.

Quand deux utilisateurs Proton s'écrivent entre eux, le chiffrement de bout en bout (E2E) fonctionne. Personne d'autre ne peut lire le contenu. Mais dès qu'un utilisateur Proton envoie un email à une adresse Gmail, Orange ou Outlook, le message sort du périmètre chiffré. Il circule via SMTP standard, arrive chez le destinataire en clair du côté serveur. Google peut le lire. Microsoft aussi. Les techniques visant à contourner ce problème en hébergeant un message sur les serveurs de Proton restent un peu chaotiques.

C'est la limite fondamentale de l'email : il est universel parce qu'il est interopérable, et il est interopérable parce qu'il repose sur un protocole commun sans chiffrement E2E natif. PGP (Pretty Good Privacy), qui aurait pu devenir la solution, existe depuis 1991. Mais, il n'a jamais percé au-delà d'un cercle technique restreint. Sa complexité d'utilisation, l'absence de standard imposé et le manque d'intégration dans les clients email grand public l'ont condamné à rester marginal. S/MIME, son équivalent en entreprise, souffre des mêmes problèmes.

Des standards pour chiffrer le transfert seulement

Il existe des standards plus récents pour sécuriser au moins le transport des emails entre serveurs. MTA-STS (Mail Transfer Agent Strict Transport Security) force l'utilisation du chiffrement TLS entre le serveur d'envoi et le serveur de réception. Concrètement : sans MTA-STS, un attaquant positionné entre deux serveurs email peut forcer une connexion non chiffrée et intercepter les messages. Avec MTA-STS, ce type d'attaque (Man-In-The-Middle) est rendu beaucoup plus difficile.

DANE (DNS-based Authentication of Named Entities) va plus loin. Ce dernier permet de vérifier l'authenticité du certificat du serveur destinataire via le DNS, sans dépendre d'autorités de certification tierces. Comme nous le rapportions dans notre décryptage sur les DNS et les certificats SSL, la gouvernance du DNS échappe elle aussi à l'Europe - ce qui complique l'adoption de DANE à grande échelle, puisqu'elle nécessite DNSSEC, une extension que tous les opérateurs n'ont pas encore déployée.

Ces standards existent et répondent à de vrais problèmes. Mais leur adoption reste faible. Et surtout, ils ne protègent les données qu'en transit entre serveurs. Une fois stocké chez Google ou Microsoft, le contenu d'un email reste accessible à ces acteurs.

L'IETF fixe les règles du jeu email, sans l'Europe

L'IETF publie les RFC, des documents de référence définissant le fonctionnement d'internet, y compris les protocoles de l'email. Elle est ouverte à tous, fonctionne par consensus, et ses décisions s'imposent de fait à l'ensemble des acteurs du réseau. Sur le papier, c'est un modèle de gouvernance ouvert et non propriétaire.

Dans les faits, les contributeurs actifs à l'IETF sont majoritairement issus de grandes entreprises américaines, parmi lesquelles Google, Cisco, Apple, Microsoft, et de quelques acteurs asiatiques. Les États européens n'y ont pas de représentation formelle. La Commission européenne peut participer, mais elle ne dispose d'aucun levier institutionnel pour imposer une direction. Quand un standard email est adopté à l'IETF, il l'est sans que l'Europe ait pesé de façon significative dans le processus.

Encore une fois, l'Europe utilise des couches fondamentales d'internet, mais ne les conçoit pas, tout comme elle n'a pas investi dans des câbles sous-marins. Elle peut légiférer sur les usages, imposer le RGPD, le DSA, ou le DMA, mais n'a aucun pouvoir sur les protocoles. Or parfois, ce sont les protocoles qui déterminent les dépendances réelles.

Héberger sa messagerie en France ne change pas les règles du protocole

Il n'en reste pas moins qu'adopter Proton, Infomaniak, Tuta ou La Poste Mail, a du sens pour qui cherche à limiter son exposition aux GAFAM. Ces services hébergent les données sur des serveurs européens, appliquent des législations locales, et offrent pour certains un chiffrement plus poussé dans leur propre écosystème.

Il n'empêche qu'aucun d'eux ne s'affranchit de SMTP. Tous envoient et reçoivent des emails via le même protocole de 1982. Tous doivent se conformer aux règles de délivrabilité fixées par Gmail et Outlook pour que leurs emails arrivent à destination. Et tous perdent le bénéfice du chiffrement E2E dès qu'un message sort de leur périmètre propre vers un service tiers.